Conversation
… Correlates that reuse the same correlation id
| * <a href="https://issues.apache.org/jira/browse/CALCITE-7753">[CALCITE-7753] | ||
| * CorrelateProjectExtractor corrupts plans with nested Correlates that reuse | ||
| * the same correlation id</a>. */ | ||
| @Test void testNestedCorrelatesSharingCorrelationId() { |
There was a problem hiding this comment.
As mentioned in jira: it is not reproducible with pure SQL in Calcite
There was a problem hiding this comment.
Because the bug requires two nested Correlates that share the same correlation id, and pure SQL (in Calcite) never produces that shape: Calcite's SqlToRelConverter gives every correlated subquery scope its own id.
|
I left a comment related to this in Jira questioning whether this fix belongs in Calcite. |
| boolean rightRebindsCorrelationId = | ||
| rebindsCorrelationId(right, correlate.getCorrelationId()); |
There was a problem hiding this comment.
I am wondering if its possible to plug the fix in findCorrelationDependentCalls to avoid traversing again a potentially large sub plan? How about stopping traversal inside findCorrelationDependentCalls if we encounter a correlate with the same id?
There was a problem hiding this comment.
@snuyanzin can you please answer this question?
It would be nice to merge this PR
There was a problem hiding this comment.
thank you for taking a look and sorry for the delay
I'll provide more info on Monday, so far with limited internet access
There was a problem hiding this comment.
thank you for the feedback @zabetak it looks reasonable, applied
also tested Flink code with this change
1f47f48 to
fb9a626
Compare
|



Jira Link
CALCITE-7753
Changes Proposed
The change to fix
CorrelateProjectExtractorfor downstream projects